The life of most code in is maintenance therefore it is good to have conventions.

The conventions are not intended to be too strict.

The conventions are based on Sun’s recommendations and are what most books use.

Naming files with extensions, packages, classes, interfaces, methods, variables and constants.

Java source is .java

Java "binary" bytecode file is .class

Application compilation make file

Readme

A collection of classes that work together to provide some kind of service. Generally used as utility services to an application.

The unique naming convention is so that the packages if distributed to the world will have a unique name.

Nouns, first letter of each word capitalized.

Nouns, first letter of each word capitalized.

Verbs, first letter is lower case, other internal words first letter is capitalized.

Variables are in mixed case with a lowercase first letter. Internal words start with capital letters.

All letters are capitalized.

This has two major parts:

1. Overall structure of items in a file.
2. Structure of code statements.

Keep files small.

Three major sections:

1. Beginning Comments
2. Package and Import Statements
3. Class or Interface Declaration

Information about class, author, version, revisions, copyrights.

All packages and imports if any that are needed.

The public class or interface declared first, then other types.

Each class or interface has seven section to it:

1. Class/Interface documentation comments
2. Class or Interface statements
3. Class/Interface implementation comments
4. Class (static) variables
5. Instance variables
6. Constructors
7. Methods

Documentation that describes the class/interface as in accordance with the format used by javadoc.

Java source code statements that declare the class or interface.

Comments about the implementation of the class. These comments are not to be revealed to the user (could be another programmer) of the class. These comments describe the algorithmic nature (the why of the code) of the class. Do NOT write comments that are redundant of what the code does.

The variables that are class wide and exist even before the object is instantiated.

The variables that are class wide and exist after the object is instantiated.

All the constructors of the object. Always code a default constructor. Don’t allow the Java environment implicitly provide one.

Group methods within the class by functionality, not by access modifier (public, private, etc…).

Methods have a structure within themselves. Documentation (javadoc) comments go before the method declaration. Implementation comments go after the method declaration. Then method variables and then code logic statements. The next section Source Statement Structure provides more information about this structure.

Format source code statements for readability and the avoidance of errors because of implied syntax or dangling characters.

One statement per line, even for variable declarations of the same type.

Less than 70 characters is best. Line wrapping is covered below.

Use indentation to make code readable but be careful about the indentation conveying meaning of logic flow that is not correct. This is most likely to happen with loops and conditionals.

Use whitespace to distinguish between keywords and methods.

If long lines can’t be avoided to format them for readability.

Put variables at beginning of class/interface and methods.

Don’t use in-line variable declaration.

Even though not always required by Java, initialize variables; aids in understandability.

No space after method name and ( of the argument list.

Align { and } on separate line on the left.

Some will NOT like this, they prefer the dangling { at end of statements.

Dangling is the more widely accepted.

I find it leads to errors when reading and updating code.

Use whatever method you prefer.

Same { } format as above.

Don’t need to use ( ) unless it makes the value more obvious.

Same { } format as above.

Use good indentation.

Use separate lines.

Use explicit coding, basically the if, if-else format.

Same { } format as above.

Use good indentation.

Same { } format as above.

Use good indentation.

Same { } format as above.

Use good indentation.

Same { } format as above.

Use good indentation.

Indicate if fall-through logic is to occur.

Always code a default case.

Same { } format as above.

Use good indentation.

Use separate lines.

Good coding techniques

Provide access to variables via methods.

Don’t hardcode anything.

One statement per line rule.

Don’t use embedded assignments.

Explicit code rule. Don’t assume others know the precedence rules.

Learn to use the "?" conditional operator

Learn to use the "?" conditional operator

Dealing with bogus/broken code.

Explicit code rule.

Portability and 100% Pure Java

Documentation (javadoc) comments and Implementation comments

Documents how, why, algorithm of the code. Indented for the programmer who maintains the code, not for the programmer who uses the code.

Align on the *

Documents the public interface to the object. Indented for the programmer who uses the class so that they know what methods are available, the parameters required and what the method does and returns.